Cream of the Crop 22

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 22 / Cream of the Crop 22.iso / games / bcrew12e.zip / BCFILES.ZIP / BCREW / DOCUMENT / GM.TXT < prev next >

Wrap

Text File | 1995-03-28 | 80KB | 2,787 lines

1╛ BRIDGE CREW GM GAME MANUAL BRIDGE CREW version sw1.12d Bridge Crew is a trademark of Mithril Software. This product is copyright Mithril Software 1994, 1995 All rights reserved. Acknowledgements Bridge Crew would not have been possible without the assistance of many people who have given their time and effort with little expectation of reward. We would like to thank those who have been involved: Programming Robert Cox, David Swan, Brenton Ross, Peter Mazzarol Technical Assistance Robbie Matthews, David Boffinger Scenario Design Robert Cox, Roger Nicholls, Peter Wass, Barbara Hall, Trish Crowther. Documentation Robert Cox, Trish Crowther, Peter Wass, Barbara Hall, David Swan. Play Testing Robert Cox, Roger Nicholls, Barbara Hall, Peter Wass, Catherine Cook, Trish Crowther, David Swan, Michael Swan, Craig Alexander, Clinton Moore-Crouch, Brenton Ross, David Boffinger, Peter Mazzarol, Scott Yates, Rodney Kearins, Kevin Maclean, Robbie Matthews, David Readman, Wes Nicholson, Nick Prosser, Ian Windorf. Introduction Welcome to the world of computer assisted co-operative role-playing. Bridge Crew is the first of a series of computer assisted multi- player role-playing games designed to be played on the current (read previous) generation of high power DOS PC's. BRIDGE CREW is played with a game master who designs a scenario for the players and may get actively involved during the playing of the scenario. Whilst non combat scenarios can be built, it is essentially a combat driven game, hence most scenarios have starship combat. Each player has a computer terminal or Personal Computer with which he/she can pull up various reports about the state of the ship and the state of the universe. He/she can also enter commands that relate to the player's assigned functions (e.g. the helm officer can set course and speed). Like the bridge of a modern warship, the captain gives orders and expects the crew to either obey or make sensible alternative suggestions. The crew is expected to run the relevant parts of the ship without specific orders. Copyright Mithril Software Page 1 SOFTWARE INSTALLATION The software is supplied in compressed (.ZIP) format on high density diskettes. You can install Bridge Crew onto any hard disk drive. By using the shareware program PKUNZIP. Specific instructions on how to wire and setup BRIDGE CREW are included in the files GETSTART.TXT and ONESTART.TXT. The software is supplied and should be placed in a directory C:\BCREW The scenario and data files should be places in C:\UNIVERSE. If you don't have a drive C: then you will need to set the environment variable BCREW see below. ****IMPORTANT***** Before installing the software, read README.TXT. Any changes have been included in README.TXT. Setting up the software (Bcrewset.bat) A setup program is provided which must be run from the directory to which you copied the program files. This program configures Bridge Crew to suit the specific hardware installed (i.e. daisy-chaining or a multi- port card). Enter BCREWSET at the DOS prompt: >C: >CD \BCREW >BCREWSET Environment variables If you do not want to run Bridge Crew from the C:\BCREW directory, then you must set the environment variable BCREW using the command >SET BCREW=C:\your directory\ Drives other than C are also supported. Eg: >SET BCREW=D:\your directory\ Most people would add this command to the AUTOEXEC.BAT file. Copyright Mithril Software Page 2 The main screen of the setup BCREWSET program is shown below: ----------------------------------------------------------- BRIDGE CREW SETUP PROGRAM 1 - Game Details 2 - Hardware Details 3 - Exit and save 4 - Quit (Dont Save) Enter Option 4 Note - remember to exit using 3 if you make changes. -------------------------------------------------------------- A display of the Game details screen is shown below: -------------------------------------------------------------- Game Details BRIDGE CREW SETUP PROGRAM GRAPHICS MODE 1 0=VGA 1=EGA 2=CGA COLOR SCHEME 1 0=16Colour 1=8Colour 2=2Colour 3=4Colour 4=CGA WORLD DIRECTORY c:\universe\ GM Port 2 COM1 (Port 0) 1 COM7 (Port 6) 0 0=No terminal (or mouse) COM2 (Port 1) 1 COM8 (Port 7) 0 1=Dumb Terminal Present COM3 (Port 2) 1 COM9 (Port 8) 0 2=PC running BCTERM COM4 (Port 3) 1 COM10 (Port 9) 0 With or without COM5 (Port 4) 0 COM11 (Port 10) 0 daisy chained terminal COM6 (Port 5) 0 COM12 (Port 11) 0 --------------------------------------------------------------- Note: It is generally better to use EGA because of the smoother screen refresh even on VGA systems. Note: Colour Scheme 1 is designed for use with a 8 shades of grey projection panel. For a colour monitor 0 is much better. Note: CGA looks crummy and will not be supported in future releases. Note: World directory must end with a \ Note: The world directory must not have a trailing space Copyright Mithril Software Page 3 Hardware Details (using COM1 and COM2) The following is a setup for just using com1 and com2: ---------------------------------------------------------------------- BRIDGE CREW SETUP PROGRAM (Hardware Configuration) Extra Ports 0 0=NONE 1=Multi Port Card 2=DOS (4 port) Interupt IRQ number 5 (Usually 2 or 5) Number of extra ports 8 (Usually 2 4 or 8) COM3 (Port 2) 180 COM4 (Port 3) 188 COM5 (Port 4) 190 COM6 (Port 5) 198 COM7 (Port 6) 1a0 COM2 (Port 7) 1a8 COM9 (Port 8) 1b0 COM10 (Port 9) 1b8 COM11 (Port 10) 1c0 COM12 (Port 11) 1c8 ------------------------------------------------------------------ This shows the setup to use just COM1: and COM2: (the standard dos ports). The important bit is to set the Extra Ports to 0 all other parameter will be ignored. NOTE: the hardware option 2 DOS (4 port) does not work and will be removed from future versions. Copyright Mithril Software Page 4 The following setup is for a uninteligent multiport card with 8 ports Hardware Details (using AST compatible or Programax-8X card) -------------------------------------------------------------------- BRIDGE CREW SETUP PROGRAM (Hardware Configuration) Extra Ports 1 0=NONE 1=Multi Port Card 2=DOS (4 port) Interupt IRQ number 5 (Usually 2 or 5) Number of extra ports 8 (Usually 2 4 or 8) COM3 (Port 2) 180 COM4 (Port 3) 188 COM5 (Port 4) 190 COM6 (Port 5) 198 COM7 (Port 6) 1a0 COM2 (Port 7) 1a8 COM9 (Port 8) 1b0 COM10 (Port 9) 1b8 COM11 (Port 10) 1c0 COM12 (Port 11) 1c8 --------------------------------------------------------------------- This shows the setup for a Programax 8X card the switch settings on the card will need to be set to : IRQ 5 (Switch S1) I/O address 180H (switch S2) Uart latch 1C0H (switch S3 (optional UART IO)) Note - It should be possible to use interrupt 2 instead of 5 provided you set "Interupt IRQ number 2 (Usually 2 or 5)" in the bcrewset program and IRQ 2 on the card (Switch S1). Copyright Mithril Software Page 5 How Bridge crew handles multi port cards. Bridge crew expects COM1 and COM2 to occupy the 'standard' I/O addresses and use the interrupts shown below: COM1 H3F8,IRQ4 COM2 H2F8,IRQ3 There aren't really standard I/O addresses and interrupts for COM3 and COM4. The most common arrangements seem to have them as shown below: COM3 H3E8,IRQ4 COM4 H2E8,IRQ3 As you will notice, the interrupts are the same as COM1 and COM2. Unfortunately this arrangement will not work with Bridge Crew. Bridge Crew expects all ports above COM1 and COM2 to share one interrupt and to be using a different interrupt to COM1 and COM2. This is the way that the AST and prograMAX-8 cards work. Using this system, many ports may share one interrupt and Bridge Crew I/O will run happily. This is also the system used by XENIX, UNIX and Coherent so most cards that will support those operating systems will also work with bridge crew. In theory any multi port card that has 2 to 8 ports, can share interrupts and uses a standard configuration of (8250 or 16450) compatible UARTS should in theory work. Some cards are 'intelligent' and operate with UNIX intelligently. These are generally expensive cards that have their own CPU and memory. They deal with character streams as packets and will not run with Bridge Crew unless configured to emulate a dumb card (which some of them can do if you set the right jumpers/switches). Because of the different strategies for the placement of I/O addresses within memory and the use of various different interrupt lines, Bridge Crew comes with a set-up program that enables users to configure the specific multi-port card that is in use. Notes about the various multi port cards that we have tried. AST compatible 4 port cards Number of ports: 4 Works fine if you do not load the drivers supplied. Available from Mithril software for $145 (includes postage). PRONET-8 (prograMAX-8) Number of ports: 8 Works fine if you do not load the drivers supplied. Available from Mithril software for $340 (includes postage). Copyright Mithril Software Page 6 DFI (COM-400) Number of ports: 4 This card refuses to share interrupts across its second 2 ports so can at best be used as a 2 port card. GW451C Number of ports: 2 This card works fine as COM1 and COM2 but will not operate as COM3 and COM4. It is not suitable to add 'extra' ports to Bridge Crew. This card is typical of most cheap 2 port cards. Support For the shareware version of Bridge Crew support is limited to the 'Self Help' system. If you can't find somone to help you then that's too bad. However David Readman has sugested you contact him on the internet on JAGUAR@WERPLE.MIRA.NET.AU To register and get your questions answered contact: Mithril Software Pty Ltd PO Box 225 Kippax ACT 2615 FAX within australia (06) 254 6280 Eg (international access code) 61 6 254 6280 Eg from the USA 011 61 6 254 6280 Copyright Mithril Software Page 7 Getting Started To start your first scenario, set up the system as described in GETSTART.TXT or ONESTART.TXT Alternativly run the setup BCREWSET program to tell BRIDGE CREW about your serial port configuration, and about the terminals on which the game will be run. if you are running daisy-chained terminals you will need to load the files BCTERM.EXE, BCTERSET.EXE and BCTERSET.DAT onto the PCs running in the daisy chain. We also provide a dumb terminal emulator called VT100.EXE which you can used to make a PC emulate a dumb terminal. The communications software is pre-set for 9600 BAUD, 8 data bits and 1 stop bit. No flow control is used, so configure the VT100 emulators or compatible terminals to these settings. At the DOS prompt, type >CD \BCREW where BCREW is the directory that contains the Bridge Crew program. Type >BCREW PUB1.SSW The program will display a title screen. Press Enter to proceed - the title screen will disappear. The program will initialise the COMM ports, and display their status. If a COMM port shows a negative status, it would normally mean a communications error. If all goes well, the main console display will be shown. This will update every two seconds (check the charging of the shields to confirm this). The terminals will now respond to the pressing of the enter key with a '>' prompt. Type the command WHO on the GM's terminal to ensure that the GM starts with all security codes assigned to him or her. If not, rerun bcrewset. Tell the person who will be playing the part of the security officer to enter the command WHO, (this will return his or her port number),the GM should then use the SECUR port_number command to assign security to the security officer on this port. Stopping the game To stop the game, enter a # (Shift 3 on most keyboards) on the main keyboard (not the GM's terminal). To restart the game after a pause (eg Helm Hit) use the shift 7 or andpersand (&) character. Copyright Mithril Software Page 8 Notes about How the Game Plays Ship Recognition or Who sees Whom? The Bridge Crew software maintains five lists of ships. These are: Visible ships: These can be seen by the command 'RECON' and have two visibility states; 'Clearly Visible' and 'Visible'. If a ship is clearly visible, it will display on the main screen as a silhouette. If not, it will appear as a blob (normally of varying size). This list is used by the 'MODE TACTICAL' display. Known Ships: This is a list of ships that are known to the players. It is the list shown by the 'THINGS' command and contains all objects that are known to the player's side. Known ships are always displayed at their last known location. This is the list used by the MODE STRATEGIC display. As DSF Command knows about these ships, it will periodically update their positions based on subspace radio intercept and sensors, or sightings. This action causes the strategy officer to receive the message "Position update shipid". The GM may at any time update the last known position of a ship on this list by using the IUPDATE command. Unknown ships: This is a list of ships that are in the game but that are not known to the players. They are noted on the LOCATE command as unknown. Note: Unknown ships will become known if they are within sensor range of a friendly ship or if they are made known by the GM (using the KNOWN command). Inactive ships: These ships have been taken out of play by the GM using the DEACTIVATE command, or have been destroyed by enemy fire. They can be listed using the INACTIVE and the LOCATE commands. Ships that have been deactivated (rather than killed) can be re-introduced into the game by the command ACTIVATE. Copyright Mithril Software Page 9 Non-Player Location list: The non player (Hostile and Neutral) ships also maintain a list of the last known positions of the players' ships. This list (which always contains all ships) also contains the visibility status of the players' ship(s). The GM commands XTHINGS and XRECON use this list. The last known location of the players' ship(s) is periodically updated on this list, but since this only occurs randomly about every 10 minutes, the GM may force the position to be updated for a specific ship using the XUPDATE command. This command immediately updates the position of the requested ship for the (computer moderated) non-player ships. This prevents the non-player ships endlessly circling the last known position of the player ship(s). When using transporters or giving orders, you will discover that player commands are at times ignored by the subject ship. The most common reason for this is that the non-player ships report to a different admiral. The GM can find the admiral by using the REP8 command. Valid admirals are: 0 Free and Independent 1 FIP Deep Space Fleet 2 FIP Merchant Marine 3 Hostile. The players can only ORDER ships that come under the command of Admiral DSF (side DSF). However if a CONDITION RED is declared, Ships under the command of Admiral FIP (SIDE MER and SIDE FIP) will also obey the ORDER command. Copyright Mithril Software Page 10 Randomness in the Game There are several actions where randomness is used to add to the game play and ensure that the same scenario will rarely play in the same way twice. 1. Non player crew efficiency. This is the probability that the non- player crew will make the correct decisions in a given two second turn. There is a different crew efficiency figure for all of the ten imaginary crew functions (helm, missile, beam, etc.). This can be determined using the REP2 command 2. Damage allocation. When hits get through the shield one function (chosen randomly) can take up to 1/2 the damage. The rest is spread around more or less evenly (i.e. for each point, a random function is selected). 3. Position updates. These occur at random intervals. For example, in the FIP universe, they average one update every ten minutes, (depending on the race, ship, class, etc.). 4. Damage chances. The percentage probability of function failure (eg a misfire) is 100 less the current performance of the weapon. 5. There is a pseudo-random time delay - e.g. how rapidly other ships respond to messages - "ID" "STATUS" etc. Copyright Mithril Software Page 11 Game Mastering As the GM you have limited control of the game during play. One of the important things to remember is the fact that once combat is entered into, things happen very quickly and the players can be destroyed before you can react. This is a game where strategy is real time (though not hurried or heavily dependent on reflexes, as in an arcade game). The basic scenarios supplied give you a universe and a series of campaigns to take the players through. YOU are expected to embellish the play by intervening at various intervals to keep the game exciting and even to modify the scenarios before play begins in order to change them to fit in with your view of the universe. 1 Your job as the GM involves the following steps: Your job as the GM involves the following steps 1. Study the System (so that you know what you are doing). 2. Set the Stage. 3. Running a Campaign. 4. Awarding OER ratings, Developing the characters and giving Decorations 5. Keeping Characters that Play Well Alive. 6. Mercilessly Killing Characters That Play Badly. 7. Keeping the Players Happy. 1. Study the system You have quite a few extra commands to learn as the GM. In addition, you should know all the player commands. You will need to have a working knowledge of the way non-player ships react and why, as well as some understanding of starship tactics. It is sensible to play PUB1.SSW as a player to get a feel for the duties of each position and to become familiar with all the commands. Do not expect to understand the system in less than twenty hours of play. 2. Set the stage Think out each scenario, keep records of players' achievements, ranks, etc. Don't let the game become boring (or "What shall we kill this week, Captain?") Think about the universe: The game includes several variables that affect the entire universe. These are set using the SETV and SETP commands and should, in theory, be constant for the entire universe. 3. Only relevant in the Registered (Full) version. In the shareware version only limited campains are possible due to the limited number of ships Copyright Mithril Software Page 12 4. Awarding OER ratings. Characters' Tour of Duty: We have conveniently placed a tour of duty at 3 scenarios. There is no need for a GM to stick to this number, however it is a lot harder to keep the players alive (while keeping the game exciting) in this kind of world than in a traditional role-play world. For example, making a tour of duty consist of 25 scenarios would make it unlikely that you would have any surviving players! Officer Efficiency Rating: The OER is designed to fill in for the common or garden variety experience point system found in the traditional role-play games. It gives the players some feedback and assists the GM in assessing how a player / character is performing. Score Meaning 5 The Character has performed excellently. Virtually all decisions and actions were correct and timely. 4 The character has performed well, but not excellently. Decisions and actions were generally correct and timely. 3 The character has performed adequately. This rating is a pass and should not be looked down on. The character is competent and can be trusted to perform well. 2 The character failed in a minor way. This is specifically a matter that did not result in loss of life or property. 1 Fail. Bad, very bad, not good. Get the picture? Decorations: Decorations may be recommended by the captain (or any 2 bridge officers) and the Admiralty (GM) will decide if the decoration should be awarded. Decorations for any universe are listed in the Player World books. The shareware version does not come with a world book. 5. Keeping characters that play well alive. This actually requires a bit of skill. First of all, you must be able to judge good play and secondly, you must avoid overmatching (pitting the players against an unbeatable foe). Copyright Mithril Software Page 13 6. Mercilessly Killing Characters that play badly. This function is relatively easy since the way to tell if they are playing well is to give them a difficult live scenario with a heavy accent on combat. 7. Keeping the players happy. Whilst the novelty of the game will amuse the players for a while,to run an interesting ongoing campaign, you will need (as with all role- playing) to ensure that the majority of players enjoy the majority of scenarios. Look for signs of disquiet. These would include: Players not turning up. Players griping about the unfairness of the scenarios. Players griping about other players without a lot of cause. Players feeling that the GM is out to get them (Actually a little of this feeling is quite good since it permits the player to feel triumphant when they succeed or survive. GMs could learn to act defeated if the players succeed in a difficult scenario. This is good for player morale.) The GM must also ensure that all players get a chance to play captain and other bridge functions if they desire. Play testing has shown that not all players want to be captain. GMs should be aware of players' feelings of responsibility towards other players. In the event of limited terminals being available, ensure that they get a fair run at the game (share of the terminals). While some gaming groups take easily to computer gaming, others will need significant running of training scenarios to develop keyboard and strategy skills. GMs should assess the special needs of new players entering a currently running campaign. Running Campaigns The Registered version is better suited to running campains because of the larger number of ships and ship classes it supports. GMs are advised to review the multi-line messages prior to play. Multi line messages use the commands: COMP GET REPORT COMPUTER DOWN XDOWN For further details, see the GM's COMP command. Copyright Mithril Software Page 14 Customising Your Universe Because no two GMs imagine the same universe, small degree of customising is possible in the BRIDGE CREW game. This customisation should, in theory, be consistient within a given universe. Therefore GMs should either modify all scenarios, or write a common script file to set all the universe parameters to the settings he or she is happy with. The following universe parameters are supported: The following universe parameters are supported: HELM HIT OVERHEATING INTEGRITY AUTO VIEW DIST SPEED HEAT DAMAGE CLOAK RAND MOVE ENERGY HELM HIT Possible values: YES or NO Function: To stop play when a crewmember is killed in the helm of the players' starship. Effect on play : Allows the GM to remove dead players as they are killed. We suggest a saving throw for all players on the bridge. The one that fails by most points is removed. This affects combat immediately, since security etc, will need to be re-assigned. Other role-playing effects are possible. Eg if you have spare crew in the ready room, you may wish to have a replacement walk in and take the dead crew member's place. The ship's doctor could be involved - the possibilities are limited only by your imagination. To continue when the helm has been hit, type a single & (shift 7) character on the main console. Copyright Mithril Software Page 15 OVERHEATING Possible values: YES or NO Function: To cause the warp engines to malfunction when the engine temprature reaches 100. Effect on play : Slows non player ships. Allows the GM to force the crew to manage the engine temperature as well as energy. With the scenario designer's kit, it allows the creation of ships with crews gungho enough to blow up their own engines. Engine temperature may rise on any turn when both the requested speed and the ship's actual speed is above the ship's maximum safe speed. See the player game manual on "Heat Strain". INTEGRITY Possible values: YES or NO Function: To cause the ship to fall apart if the function 'Hull' reaches 0. Effect on play:Reduces the average amount of damage that ships can sustain. Forces the crew to repair the hull function. The INTEGRITY parameter is best used in conjunction with the scenario designer's kit to enable variations on the damage control strategy required to keep ships alive. AUTO VIEW Possible values: YES or NO Function: To allow the helm comand AUTOVIEW to work. Effect on play : Gives the helmsman the option of not having to center the starship at regular intervals. Reduces the visual feedback associated with the players ship moving - this can can confuse new players. Copyright Mithril Software Page 16 DIST SPEED Possible values: YES or NO Function: To cause the detail command to display last known heading and speed. Effect on play: Increases information available to the players. Note: The rationale behind this variable is that the technology used to track starships may or may not provide this level of detail. As an historical note, radio intercept during world war two did not provide any information other than aproximate location. HEAT DAMAGE Possible values: 0 to 32000 Function: This value is the maximum damage that will be done when an engine overheats. The actual damage is a random number between 1 and the value set with the command. Effect on play : If this value is high, it seriously increases the risk of major engine damage when overheating of the engine occurs. Eg, if the value is set to 100, then up to 100 points of damage can be done in one turn. If the engines are allowed to overheat, the average damage will be 50. CLOAK RAND Possible values: 0 to 1000 Function: To give a fixed probability (in tenths of percent) that a cloaked vessel will de-cloak on a given turn. Effect on play : To vary the visibility of cloaked vessels by making them de-cloak more often. Example values: 0 Ships will not randomly de cloak 10 Ships will decloak 1% of the turns (roughly once each 3 mins) 100 Ships will decloak 10% of the turns (or about once each 20 seconds) Copyright Mithril Software Page 17 MOVE ENERGY Possible values: 0 to 100 Function: To to alter the calculation of energy used; by allowing the calculation of energy used at a given speed to be based on actual speed or requested speed. Effect on play: Removes or enables a technique coined by the player that discovered it as 'Speed Osciliation'. This relies upon setting speed 80 till the battery is flat then setting speed 0 until the battery is recharged (which on a monarch takes about 3 turns) then setting speed 80 again. By doing this, a Monarch can maintain an average speed of about 77 and never run out of energy. Example settings: 0 Energy usage is entierly based on requested speed. 50 Energy usage is based half on the requested speed and half on the actual speed. 100 Energy usage is entierly based on actual speed. Copyright Mithril Software Page 18 Role-play systems If you are using GURPS , Traveller , or any other SF (or fantasy?) role- play system then you can ignore the role-play rules supplied with the registered version and use the ones supplied with the role-play system you are using. Note however, that long tours of duty of (E.g. 25 missions) are very unlikely to have any survivors, so I would suggest that a dice roll be used to determine how many 'interesting' missions go into a tour of duty (i.e. you don't play 25 missions, only the one to six interesting ones). GMs should not disclose how many interesting missions are in a particular tour of duty if this method is adopted. Roll two six sided dice 2-3 1 interesting mission 4-5 2 interesting missions 6-8 3 interesting missions 9-10 4 interesting missions 11 5 interesting missions 12 6 interesting missions Obviously with alternate game systems some thought will need to be given to the required qualifications and stats for bridge officers. Copyright Mithril Software Page 19 Player Commands The player commands are included in the Bridge Crew player manual. The GM must be familiar with the player commands and their function. This chapter contains supplementary information about those commands that is useful to the GM. ARC angle weapon_list Sets the dispersion angle of the beam weapons. In the current version of Bridge Crew, no advantage can be gained from setting it to anything other than the default (10). In the current universes (FIP and Shareware) ASSIGN function1 number function2 Note that if the DC function is damaged you can only order crew to and from the bridge (HELM) until it is repaired. BLOCK target weapon_list It can take the computer up to ten (10) turns to unlock from a destryed vessel. BUNLOCK weapon_list This command has no effect on non-player ships, but has been added to enhance role-playing. CHARGE weapon_list or BCHARGE weapon_list The crew will get the rather vague message 'no ammo' if there is insufficient energy to start the charging process. On an energy starved ship, it can take a very long time to charge the beam weapons. COURSE angle This command is affected by the performance of the HELM function, so if you are not turning check your helm for damage or lack of crew. DELETE message_number Don't confuse this player command with the GM command XDELETE. DETAIL ship This command is affected by the setting of the DIST SPEED parameter. DIRECT end_location [start_location] This command is really useful when you are setting up scenarios. Copyright Mithril Software Page 20 ETA start_location speed end_location Another command that is useful when you are setting up scenarios. FROM ship_id start_ship_id Remember that inactive and unknown ships do not appear on this report. Remember that the last known location is displayed (not the current location) FUNCTION function_id You may find that players complain the a function is not repairing or that transporting or assigning to a function do not work. This command can be used to assist you in determining why these things are not happening. The function_id can be found from the command REPORT FUNCTIONS. GET message number Don't forget that messages can be set up using the COMP command. LOAD weapon_list or MLOAD weapon_list Crew will get the rather vague message 'no ammo' if there is insufficient energy to start the charging process. This message can also mean that the missile magazine is empty. MUNLOCK weapon_list This command has no effect on non-player ships, but has been added to enhance role-playing. LOG text This is stored in a file called BCREWLOG.DAT, which can be viewed after play using the usual DOS commands for text file viewing. MACRO number text As the GM, you can use any command as a MACRO MFIRE weapon_list Don't forget that ships carry a limited number of missiles which you can reload at any time with the XRELOAD command. MODIFY dsf_ship angle distance These parameters are not used once combat is entered except for ships currently governed by the FLEET command. MODSPEED dsf_ship speed [rotate] These parameters are not used once combat is entered except for ships currently governed by the FLEET command. Copyright Mithril Software Page 21 The ORDER command ORDER dsf_ship mission details Orders a ship to a specific mission type. Where mission details include the following commands. ATTACK target ship The ship will move toward and try to intercept the target ship. If the ship is not detected by the sensors, it will move towards the last known location of the target ship. It will engage other targets of opportunity within threat distance if the target ship is not within threat distance. While in combat, hostile ships that are very close will cause the crew to 'Panic' and set other close hostiles as a priority target. This tendency to target other close hostiles rather than the ship that they have been told to attack, can be rather annoying, especially if the close hostile is trying to run away. This problem can be reduced by the clever use of the FLEET and TRADE commands. (Eg Make the ship FLEET rather than attack the target) ESCORT ship This command is similar to fleet; however if a hostile ship comes within threat distance, the ship will actively seek out the hostile ship and attack it. FLEET ship The ship will move towards and maintain station on ship if the ship is hostile it will shoot at it. If the ship is friendly then it will shoot at any hostile within threat distance. GOTO location The ship will move towards location, but accept combat on the way, ie it will head out and attack other craft. If you wish to cut a path to a location and not be deviated from your goal then use TRADE location same_loaction LOWER Lowers shields on friendly starships for ten turns so that the transporters can be used. Future versions may allow some variation on the ten turn limit. PATROL location1 location2 The ship will move from location1 to location2 and will attack any hostile within threat distance. Copyright Mithril Software Page 22 RETREAT location The ship will move towards location and avoid combat SCOUT location1 location2 The ship will move from location1 to loacation2, but will attempt to avoid combat. SHADOW ship This command allows the ship to follow another ship at a distance. The distance is defined by the captain's threat distance and for this reason ship is often defined as having captain 20, who has a suitable threat distance for shadowing in the FIP universe. TRADE location1 location2 The ship will ply the trade routes between the 2 locations pausing only long enough to transport/unload cargo at each destination. If the vessel is armed, it will shoot at any hostile it can without deviating from its course. WAIT The ship will wait at speed 0 until a hostile ship comes within the threat range of the current captaincy style, then it will attack the hostile ship. ---------------------------------------------------------------------------- QUEUE If you are GMing you have the XQUEUE command as well. Don't get them confused! READ message number Dont confuse the command with XREAD. REPORT CROSSSECTION See the section on How Sensors Work. Note: In the current release of Bridge Crew, frequency ZZ is not actually used. SCALE number You can simulate a damaged ship's view screen by periodically changing the scale. SEND The non-player ships will automatically respond to the SEND command for the following message: HELLO, STATUS, ID, and NEWS. The responses may be set with the TEXT command. The responses may be seen with the REP8 command. Copyright Mithril Software Page 23 THINGS ship_id Remember that inactive and unknown ships do not appear on this report. Remember that the last known location is displayed (not the current location). VIEW location You can simulate a damaged ship's view screen by periodically viewing from a different spot. WHO Sometimes, if security is not assigned correctly, players entering valid commands will receive the message 'Syntax Error'. You can use the REPORT SECURITY command to check if this is the problem, or advise the player to use the WHO command to check his or her security. ZONE location1 This command is generally used in live play only and players may need to be reminded of its existence. In the shareware version only PUB9.SSW has zones set up correctly. Copyright Mithril Software Page 24 GM Commands Throughout the section on commands, the following applies: Location: is the location in co-ordinates eg 303.21125 is the location where x=303 and y=21125. or it is the name of a star system or it is the Id of a starship or it is the name of a starship. In the last two options, the last known location of the starship is used by the program to determine the location. If location is the id of a starship, then actual location, rather than last known location can be specified by using the '/' character. Eg /X3 is the actual loaction of X3. Shipid is the two letter code of a ship, or the name of a ship Any portion of a command placed within square brackets is optional. ACTIVATE shipid Where shipid is the shipid of the ship you wish to activate. Makes the ship able to effect play. A badly damaged ship that is inactive through 'death of ship' will deactivate itself again on the next turn. ADJUST CREW|PASSENGERS|CASUALTIES shipid ship_function number Set a new level of crew or passengers for the shipid. This will not allow you to over-fill the ship. CAPTAIN shipid new_captain_num Change the captaincy style. Especially useful in conjunction with MISSION SHADOW. Captaincy styles mainly affect the combat characteristics of a non-player ship. Note that captain 20 is very good for shadowing, but is not good for attacking. See the section on Captaincy Styles in this manual. Copyright Mithril Software Page 25 COMBAT [start_ship] [dist_ship] This comand has two functions. Firstly it shows whether a non player ship is in combat. If it is in combat, the ship it is in combat with is shown under the heading combat. Secondly it shows all distances from dist_ship based on actual (as opposed to last known) location. Other than these differences the command is simmilar to the LOCATE command. COMP message_number line_number text This allows you to alter the multi line computer messages that have been loaded by the scenario. If no message exists in the message_number you select, it will create one there. This allows you to add extra messages when you want to. The text should have less then seventy characters. As this can take some time, it is better to run the scenario, create the messages and then save it, rather than trying to enter it during play. CREW shipid GM's equivalent of the player command REPORT CREW. Performs the command for the shipid. DAMAGE shipid function new_value Set a given shipid's function damage to a new value. Values are never set higher than the maximum original damage permitted (see player game manual Chapter How the Game Plays, subheading Ships Functions) or lower than 0. Players are not informed. This can also be used to fix a function quickly if so desired. This command can also be used by the GM to rule on spares. The normal method is for the GM to set the damage in a totally destroyed function of a player ship to one, then to send a message to explain that the jury-rigging is in place. See Also: MALFUNCTION DATE new_stardate This command allows the GM to change the stardate. this is normally used during a campaign to add continuity. EG >DATE 1146.678 Copyright Mithril Software Page 26 DEACTIVATE shipid Where shipid is the shipid of the ship you wish to remove from play. Stops the ship from actively affecting play. DMOVE shipid location angle distance This command moves shipid to a position defined by location, angle and distance. Eg DMOVE F1 X3 200 500 will place F1 500 TSU from the last known location of X3, at an angle of 20 degress (200). DMOVE F1 /X3 200 500 will place F1 500 TSU from the actual location of X3, at an angle of 20 degress (200). DOWN message_number This downloads a multi line message into the ship's computer and allows the players to GET it. ENERGY shipid List the energy used at various speeds. GM's equivalent of the player command REPORT ENERGY. EXHUME shipid Where shipid is the shipid of the ship you wish to exhume. Eg EXHUME X3 will repair all of X3's functions and stock them with crew. It will also make a guess at a suitable number of extra Damage Control crew. EXHUME will not affect the active flag, so exhumed ships will remain active or inactive as they were prior to the command EXHUME being issued. Note that shields are not recharged by the command, nor are missiles reloaded. NOTE: exhume does not adjust casualties ut will in version 1.14 FREEZE Halts movement. This command only freezes movement, not combat, stardate, etc. Copyright Mithril Software Page 27 GMGM [virtual_port_number] [COMMS] Enables virtual_port_number as a second GM terminal. If the word COMMS is added then the "Message not read" reminders will be directed to the secondary GM terminal rather than to the primary GM terminal. If virtual_port_number is omitted then the current second GM prot is listed. GUARD shipid Lists the shield status and energy state for the given shipid. The energy crisis flag is useful because it assists the GM in predicting non-players' energy management strategies. The resultant report is shown below: Front :1120 200 100% UP Right :1120 200 100% UP Back :1120 200 100% UP Left :1120 200 100% UP Battery 4000 Energy 1080 Energy Crisis 0 NOTE: if energy crisis is greater than zero then the non-player crew may be taking action to reduce energy usage in non-essential systems. The higher the value the more drastic the action. IMIT from_ship to_ship message This is a command that sends a message to the player's ship, but it is sent as a message intercepted enroute between two other ships. The message will appear in the ships message queue with the to_ship being any ship and the text INTERCEPT appended to the front of the message. At the same time, the positions of the from_ship and to_ship will be updated as if an IUPDATE had been done. INACT count Where 'count' is the number of the first ship to be listed. List up to ten inactive ships at a time. IUPDATE shipid Updates the last known location of a ship to its present location. Non- player hostile ships have a flag set in them to update their position at random intervals. If the GM specifically wants the last known position updated then he or she can use IUPDATE. The command will not work on UNKNOWN ships. Copyright Mithril Software Page 28 KNOWN shipid UNKNOWN shipid These two commands add or remove the ships from the players' THINGS display. Ships will automatically become known when a ship friendly to the players can scan them. Only known ships have their position updated periodically on the THINGS report. Ships that are unknown will be listed and indicated as such by the LOCATE command. The important play factor is that position updates are never received for unknown ships. It is polite therefor if the GM, after making a ship 'known' were to perform the IUPD command to advise the players. Also note that ships automatically become known as soon as they enter sensor range of a friendly ship. LOCATE [shipid] Where shipid is the first ship to be listed. The GM's version of the THINGS command. Lists actual position of all ships. Id Heading Distance Xpos.Ypos Known Status Class F0 0 1 500500. 195500 Yes Alive MONARCH CLASS M1 3326 917 500077. 196314 Yes Alive LIBERTY CLASS F1 900 896 501396. 195542 Yes Alive LARSON CLASS X1 160 10439 503384. 205533 Yes Alive C-7A CLASS X2 231 9779 504346. 204492 Yes Alive HC10 X3 209 10729 504344. 205517 Yes Alive F-23 CLASS S1 167 10440 503500. 205500 No Inact. MERCURY CLASS S2 167 10440 503500. 205500 No Inact. MERCURY CLASS S3 167 10440 503500. 205500 No Inact. MERCURY CLASS More MALFUNCTION shipid function new_value Where shipid is the shipid; function is the function you wish to damage and new_value is the new amount of damage points that the function has. Sets the damage for a function to a new value and sends a communication to the player ship if shipid is under the command of the same admiral as the player ship. This will not let you put more than the maximum value, or less than 0 points into a function, even if you try. Copyright Mithril Software Page 29 MISSION shipid new mission Where 'shipid' is the ship you wish to change its orders and 'new mission' is one of the following standard missions: Command Meaning wait Do nothing till further orders. escort shipid Escort and defend trade location location Move to and from pausing to load/unload shadow shipid Follow, hide, don't attack (Works best for captain 20) attack shipid Attack patrol location location Defend and watch scout location location Just watch goto location Go there fleet shipid Join a fleet and keep station retreat location Get the hell out of here lower Lower shields for ten turns. GM's version of ORDER command. See player manual. MOD1 shipid angle distance Just like the player command MODIFY but works on any ship. MOD2 shipid speed [rotate] Just like the player command MODSPEED but works on any ship Copyright Mithril Software Page 30 MOVE shipid location Where shipid is the ship to be moved and location is a ship id, a system id or an x.y co-ordinate. Move ship to the location indicated. This does not update the last known location of the ship. For example, MOVE F1 /X3 will place F1 at the actual location of X3. MOVE F1 1339.6774 will place F1 at the location 1339.6774. MPRINT ship_id [file_name] MPRINT is used to produce ships' technical details for inclusion in a manual. File_name is optional and if left out, the details will be sent to the printer. If a file name is supplied, the resultant file will be a standard dos text file. The printer is connected to LPT1 and must be a text printer (ie not a postscript printer). Note: Not all of the ships in the supplied universe are included in the manuals, only the more commonly used ones. Customers who buy the Scenario Designer's Kit will find this command useful when they are designing ships for their universe. PAUSE message Pauses the game, sending a message to the players' terminals. Eg: PAUSE TEMPORARY STOP will pause the game until an & (shift 7) is entered on the main keyboard. The message TEMPORARY STOP will appear on the main display and on all terminals. PEOPLE shipid GM's equivalent of the player command REPORT PEOPLE. Performs the command for the shipid. PICT shipid new_picture Allows the alteration of the various ship shapes. If you want a Monarch that looks like a Starbase, you can have a Monarch that looks like a starbase. Picture numbers vary from 0 to 69 - try them! QPRINT [filename] QPRINT will print a quick listing of the scenario to the printer or to a file. This is useful when you are designing or modifying scenarios. Copyright Mithril Software Page 31 REP0 shipid This is the Gm's version of the 'REPORT ENGINES' command. REP1 shipid Lists speed, heading and mission details. The report is shown below: req_speed 80 act_speed 80 req_heading 3068 act_heading 3068 mission ESCORT current_move 2 mission_ship M1 combat_ship NONE combat_curr_angle 1800 decel_dist 1066 lower 0 mission_speed 80 tactics 3 xpos 501396 ypos 195542 change_mind -1 mission rotate 0 posx1,y1 1 1 Captain 3 posx2,y2 1 1 mission_timer 0 Mission_dist 500 mission_angle 450 mission_rotate 0 Some of the more useful information on this report is requested and actual heading and requested and actual speed. This screen was used for testing, so some of the information shown may not be useful for normal play. It will be tidied up in future versions of Bridge Crew. REP2 shipid Lists crew efficiencies and reactions to energy crisis. The report is shown below: ID efficiency energy_crisis strategy HELM 80 7 15 DC 80 5 1 BEAM 80 3 0 MISS 80 3 0 COMMS 80 5 0 ENG 80 5 0 SEC 80 5 1 SHIELD 80 4 0 SCI 80 3 0 STRAT 80 5 0 COMP 80 5 1 This report will be tidied up in future versions of Bridge Crew. The lower the energy crisis amount the lower the priority that the item has for energy distribution. The strategy column defines the non-player crew strategy for that function. Since there is no way to change these without the Scenario Designer's Kit, their values are described in the Scenario Designer's Kit's documentation Copyright Mithril Software Page 32 REP3 shipid Ship's missile report. It is the same as the Player Command REPORT MISSILE, but can be performed for any shipid. Id Prox Ammo Function Perform Dam Sp End aim Status Lock PT1 0 30 MIS1 100% 300 120 10 0 Empty none PT2 0 30 MIS2 100% 300 120 10 0 Empty none End report REP4 shipid Ship's beam report. It is the same as the Player Command REPORT BEAM, but can be performed for any shipid. Id Arc Firing-Arc Function Perform Dam Aim Status Lock LP 0 2699-1 PH1 100% 300 0 Empty NONE FP 0 3149-451 PH2 100% 300 0 Empty NONE RP 0 900-0 PH3 100% 300 0 Empty NONE End report REP5 shipid Ship's echo. Reports the amount of reflectivity for that sensor type. EM 62 WS 66 SR 79 SE 61 PS 60 ZZ 64 This is a representative figure not a percentage, generally the lower the figure the harder the ship is to see. See the section on "How Sensors Work." REP6 shipid Reports sensors on another ship. Same as the player command REPORT SENSORS, but can be performed for any shipid. Id State Sensitiv Cost Range Speed Perform Function 0 SR ON 40 300 9500 0-100 100% SENS0 1 SE ON 40 100 6000 0-180 100% SENS1 2 EM ON 40 20 3500 0-9 100% SENS2 REP7 shipid Same as the player command REPORT TRANSPORTERS, but can be performed for any shipid. Copyright Mithril Software Page 33 REP8 shipid This lists the queries, chats, hellos and other set messages in the non player ships. They can be changed using the TEXT command. Note that query is updated with each new mission from the ORDER and MISSION commands. REP9 shipid This is the gm's version of the 'REPORT SHIP' command; it is the same as the players' report ship command, but works for any ship. R10 shipid This is the GM's version of the REPORT DC command. It can be run for any ship. R11 shipid Reports on the status of the cloaking device(s) installed on shipid. RESTORE file_name Restarts the game from a previously saved file. RMOVE shipid location dist Randomly move shipid to location at the given distance in TSUs. RMOVE F1 /X3 500 will place F1 at exactly 500 TSU from the actual location of X3, at a random heading. RMOVE F1 X3 500 will place F1 at exactly 500 TSU from the last known location of X3, at a random heading. SAVE file_name Saves the game to a file for later reloading. This has been disabled in the shareware version sw1.12. Copyright Mithril Software Page 34 SCENARIO [number] Scenario is used to change the scenario number for the ship's computer functions. If number is omitted, then the current scenario number is displayed. Number must be between 0 and 19. Note: The information in the ship's computer is part of the scenario file. If you wish to modify the information in the ship's computer, you will need a copy of the Scenarion Designer. There is little of value in the ships computer in the shareware version sw1.12. SCRIPT file name Where file_name is the name of the script file to be used. File_name will always end with '.scr' A script file is made up of a series of GM commands which the GM would ordinarily have to type in himself or herself. Any command usable by the GM can be put into a script file. It can be quite useful for the programming of your personal macros as it can be used in any scenario. This command starts processing a GM script file. Script files may be written with any text editor (or word processor that produces DOS text file format). They contain lists of commands that will be executed in sequence. Errors will be ignored so the GM must watch for them. (Script files are often provided with the scenarios for special events.) To stop a script file that you have started inadvertently, press % on the main computer console (not the GM's terminal). SECURITY Port_number Each player (except the captain) has a terminal (or PC running a terminal emulator) which is connected to a port on the computer running Bridge Crew. The ports have ids 0, 1, 2, 3, etc. The GM assigns security to one of the players using this command. E.g. SECURITY 0 will give the SECURITY function to the player whose terminal is plugged into port 0 on the main computer. Note that the easiest way to find the port number is to use the WHO command. Copyright Mithril Software Page 35 SETF [ON|OFF|PRESERVE] When entered with no parameters, this command displays the current value of the fake helm hit This command displays or sets fake helm hit. If it is set to ON, the next hit will be directed to Helm with exactly one casualty. If it is set to OFF, hits on the players' ship will be allocated randomly, as normal. If it is set to PRESERVE, future hits on the helm of the players' ship will be prevented. If this command is used too often, players may become suspicious. We recommend that it only be used when role-playing requires its use. SETP [HELM|OVERHEAT|INTEGRITY| AUTO|DIST] [ON|OFF] When entered with no parameters, this command displays the current values of the universe parameters. This command displays or changes the setting of the following GM universe paramaters: HELM HIT OVERHEATING INTEGRITY AUTO VIEW DIST SPEED For a full description see the section headed "Customising Your Universe". Eg SETP OVERHEATING ON sets the universe parameter OVERHEATING to on which allows engines to overheat and get damaged. SETV [HEAT|CLOAK|MOVE] [new_value] When entered with no paramaeters, this command displays the current value of the universe parameters. This command displays or changes the setting of the following GM universe paramaters: HEAT DAMAGE CLOAK RAND MOVE ENERGY For a full description see the section headed "Customising Your Universe". E.g SETV HEAT 50 sets the universe parameter HEAT DAMAGE to a value of 50 Copyright Mithril Software Page 36 SIDE shipid FIP|NEU|HOS|DSF|MER|FRE Changes the side of shipid FIP makes it part of the Federation of Independent Planets and gives it admiral 0. NEU makes it a neutral vessel answerable to nobody HOS makes it hostile to the FIP DSF makes it part of The Deep Space Fleet (admiral 1) MERchant makes it part of the FIP merchant marine (admiral 2) FRE makes the ship a free trader, but is in all ways similar to FIP. If SIDE is entered without parameters, then it will display the current side of the ship. Unfortunately in version sw1.12 these are 'hard coded' and FIP must represent the Humans Trade fleet and DSF must represent the Human military fleet. Copyright Mithril Software Page 37 SIGINT shipid Each ship has a flag attached to it which controls the probability of the ship giving its position away via an xupdate or iupdate-like process. This is a single integer between 3 and 32000; for most ships it starts at 30, which will randomly update the position, with an update occuring, on average every ten minutes. The probability of an update in a given turn can be found by the formula: PROBABILITY = 1/(SIGINT*10) Eg if sigint = 60 probability(0.0017) = 1/(60*10) This means that (on average) the ship will have a 0.17% chance of disclosing its position every two seconds (this is equally true of player and non-player ships). To convert this to the average delay until a position update, apply the following formula: TURNS = SIGINT*10 MINUTES = SIGINT/3 NOTE: The default period of ten minutes is quite long; the result of this is that non-player ships will tend to aim towards the spot where the ship was 5 minutes ago. TECHNICAL NOTE :- The probability of update follows a geometric distribution with one event every 10 turns. For example, if SIGINT = 60, an approximate 95% confidence interval for updates is 1 to 1799 turns, ie. less than 60 minutes. This means that for SIGINT = 60 there is a 95% probability that an update will occur in within the period of 60 minutes. SPARE This command will display the spare time available to the CPU (Central Processing Unit) of the computer on which you are running Bridge Crew. This command is only really needed by scenario/game designers to tell them when the number of active components of a scenario have exceeded the capicity of the CPU to deal with them in the course of a two second turn. The SPARE command can be reset as follows: >SPARE RESET SPRINT [file_id] Print a summary listing of all ships in the Scenario. The file_id is the name of a DOS file that the ship details will be sent to instead of to the line printer. Note: file_id is optional. Copyright Mithril Software Page 38 STATUS shipid Equivalent of the player command REPORT FUNCTIONS for a given shipid; it lists damage status. TEXT HELLO|QUERY|ID|NEWS|DESC| CLASS shipid new_text This command allows you to alter the set message texts for the various ships. The text can be up to sixty characters in length, except for Class, which can be 30 characters in length. UNFREEZE Allows movement. Undoes the FREEZE. USUS ship_id CONFIRM This switches the player ship to the ship_id ship. Thus if you wanted the players to play the Xingon cruiser X1 in a particular scenario, type USUS X1 CONFIRM. This command is designed to be used by the GM while setting up a new scenario. It is not designed to be used while the players are playing. XDELETE message_number Deletes a message from the GM's Queue. Similar to the player command DELETE, but works on the GM's queue rather than the player's queue. XDOWN message_number Message_number is betwwen 0 and 9. XDOWN removes one of the ten line messages from the players' access. This command is the opposite of DOWNLOAD (DOWN). Removes message access from the players. This command has no effect in version v1.12 and sw1.12 this is a bug and will be fixed in v1.13 (registed version) XFUNCTION shipid function_id Just like the player command FUNCTION but for non player ships. Note: the function_id cannot be abbreviated and may be determined by using the "status" command. XGET message_number Using this command you can access and read any of the computer messages that have been loaded into the scenario. See the section on ten-line messages. Copyright Mithril Software Page 39 XHELP command This is identical to the player HELP command except that it will only work for GM commands. XMEM The amount of available (unused) memory is listed by the XMEM command. XMIT from to message Where from is the shipid from which the message originates; to is the shipid your message has to go to; and message is the message to be transmitted; normally of one line. E.g. XMIT T1 F0 We are on route to trade at Sol. will give the player ship a message from the trading vessel "T1". Be warned that any backward arrows in the message will also be transmitted and may not behave correctly on a different terminal, so be sure to use the Back Space key for correction, not the arrow keys. Note that the message is limited to 69 characters in length. This is the GM's version of the SEND command. See the Player manual for more details. XPRINT shipid [file_id] Print the shipid on the line printer or send it to a file. The file_id is the name of a DOS file that the ship details will be sent to instead of to the line printer. Note: file_id is optional. XQUEUE Lists the communications messages that have been queued to the GM. This command is similar to the player command QUEUE, but reads from the GM's queue, rather than from the player's queue. XREAD message_number Reads a communications message from the GM's Queue. Similar to the player command READ but works on the GM's queue rather than the player's queue. Copyright Mithril Software Page 40 XRECON shipid Just like a RECON from another ship. This command is useful when you want to see the effects of cloaking and stealth technologies. XRELOAD shipid number GM's command to reload all missiles on a ship. You cannot load more than the maximum allowed in the magazine. It can also be used to remove missiles - simply set number to 0. XSEARCH key1 [key2] [key3] GM's equivalent of the player command SEARCH. Lists the first ten entries in the players' ship's computer with key1, key2 or key3. Key2 and key3 are optional. XTHINGS number shipid Similar to a THINGS for an enemy ship. Number should be the start ship number. Try 0 10 20 30 etc. This command is useful because it lists where the ship thinks that other ships are to be found. This can explain strange behaviour of non-player ships. Use XUPDATE to update the current locations on this list. A sample report is shown below: Ship head dist vis pos F0 2700 896 Vis 500500. 195500 M1 3004 1528 Vis 500077. 196314 F1 0 1 Vis 501396. 195542 X1 119 10177 Inv 503500. 205500 X2 191 9480 Inv 504500. 204500 X3 173 10430 Inv 504500. 205500 XTRANSPORT CREW num_crew TO|FROM shipid ship_function gm_ship Enables the GM to remotely transport non-player crew and passengers. The command: XTRANSPORT CREW 5 TO T1 HELM X1 could be used to move a repair crew from a Xingon ship to the helm of a stranded trader. It is sometimes easier to type in two ADJUST commands. XTRANSPORT PASSENGERS num_passengers TO|FROM shipid ship_function gm_ship Enables the GM to remotely transport passengers. As above, but taking the numbers from the passengers instead of crew numbers. To modify crew or passengers without restrictions, use the ADJUST command. Copyright Mithril Software Page 41 XUNCLOAK shipid Lowers cloaking on shipid. The effect of this command is temporary; non-player crews will try to put cloaking back up at the first possible oportunity. See the section on 'CLOAKING' for details of the play mechanics of cloaking. Note that this command will have no effect on ships that have a 'stealth' technology rather than cloak technology (such as the OWL class). XUPDATE shipid Updates all ships with the current location of the shipid. Just as the players have a list of known ships, so do the non-players. The function of this command is to inform the neutral and hostile non-player ships of the last known location of a player ship. The command can also be used to update player-friendly ships. Copyright Mithril Software Page 42 Captaincy styles and tactics Each non player ship has a specific captaincy style, the main effect of which is in combat. Basically a given captaincy style has a preferred attack angle and distance when reacting to the ATTACK, ESCORT, WAIT, and PATROL commands. The ship will enter combat and try to manoeuvre into the position dictated by the captaincy style. Two of the captaincy styles are variable and the attack angle changes after a certain number of turns. This changing tactic is useful for swooping attacks and suits certain classes of ships. More captaincy styles will be available in future releases. Some captains have a tendency to rotate around the target ship, either clockwise or anti clockwise, at varying speeds. Thirty captain types are supplied with Bridge Crew. Each captain has his or her own style, which affects how the non-player ships under his or her command manoeuvre. The captaincy style can be determined by using the GM's command REP1. The table over-leaf shows the favoured style. The headings are explained as follows: Distance Favoured combat distance Angle Favoured attack angle Rotate Whether the ship will tend to rotate, and if so, in which direction. Speed Preferred combat speed. Most ships have a maximum speed of 80, so all captains in those ships will travel at the same speed. There are some ships, however that can travel faster. If a captain with a speed of 80 is assigned to a ship with a greater maximum speed, he or she will then tend to travel more slowly than a captain with a speed of 85. Captain Distance Angle Rotate Speed 0 400 1800 No 85 1 500 1800 Clockwise 80 2 500 1800 Anticlockwise 85 3 200 1800 No 85 4 600 2500 No 80 5 400 900 No 85 6 700 270 No 80 7 150 1800 No 85 8 1000 1800 No 85 9 1500 1800 No 85 10 1000 1800 Clockwise 85 11 4500 0 Clockwise 85 12 4500 0 No 85 13 2000 1800 Clockwise 85 14 2000 0 Clockwise 85 15 600 900 No 50 16 500 0 No 85 17 500 1800 No 85 Copyright Mithril Software Page 43 18 1000 900 No 85 19 1000 2700 No 85 20 6000 1800 Very Slow Clockwise 85 21 2000 1 No 0 22 2000 1 No 120 23 2000 2700 No 120 24 2000 1800 No 120 25 2000 900 No 120 26 1000 1 No 0 27 1200 1 Fast Clockwise 90 28 1500 1 Slow Clockwise 70 29 1450 1 No 100 Notes on Captain Types Ship No Description 0 Default captain for most ships. 8 Tends to slow to speed 50 in combat. 16 & 17 Captains 16 and 17 are effectively the same - the captain style changes every 32 turns, providing the ability for the ship to swoop up and down. 18 & 19 Captains 18 and 19 are the same - the captain style changes every 39 turns, providing the ability for the ship to swoop from left to right. 20 Optimised for shadowing. 21 A speed 0 captain, suitable for FIP ships facing C7 class Xingon vessels. 22 & 23 Suitable for Rheman ships with plasma bolts. 26 This captain is less easily distracted. 28 Suitable for DDMs. 29 Suitable for double ended ships. Copyright Mithril Software Page 44 Hints and Tips Use the SIDE command to make yourself neutral and run a few combats just to see how non-player ships react with different captaincy styles. As the GM, several things can help you to control a combat: 1. Vary the captaincy styles. This stops non-player ships from lining up and getting blasted by one weapon (NB, missile weapons affect all ships witin the blast distance in the direction that the weapon is aiming.) 2. Use captaincy styles that use a greater 'favoured combat distance'. Ships under the command of such a captain will tend to hit less often with missiles and less effectively with beams; this effectively slows the combat. 3. Use swooping captaincy styles for ships with missile systems that have low manoeuvrability. Eg captains 16 and 18. 4. Use the 'FLEET' or 'TRADE' commands to break up non player ships locked in to chasing ships of equal or slightly greater speed. Eg MISS X1 TRADE XING XING 5. Use the 'DAMAGE' command to reduce the capacity of non-player ships to react sensibly, shoot, etc. 6. Use the DAMAGE command to restore non player ships in situations where it would add to the excitement. 7. Make use of 'SHADOW' where it can be used to lure the players' ships away from the ships that they are escorting. Players can then be court-martialed after the action for 'leaving the transports unprotected'. 8. If you are clever, you can load a 'DEACTIVATE' command, (to take one of the players' opponent's ships out of combat), but not press enter until a missile and/or beam weapon hits nearby. This makes the players believe they have killed the ship concerned and is useful when you have overmatched the players. Copyright Mithril Software Page 45 Limits of the Game Unless you have the scenario designer's kit you cannot: + Add or Delete ships from a scenario. (De-activated ships are still in the scenario.) + Design new ships. + Change the star background. + Re-configure any ship's performance other than by damaging it or removing crew. + Change crew strategy or performance. Only 30 ships can be shown on 'recon' at any time. GMs must avoid situations where more than 30 ships are visible at one time. GMs should avoid setting scenarios outside the square defined by the points (1,1) and (999999,999999). The point (0,0) does not exist in the universe as we know it, nor does any other point outside the square. No testing has been performed outside this area. Even if the game system is found to work outside these points, future releases may not. It is hoped, in the future, to increase the size of this square, but for the moment please stay within it. This is a game: It is important to note that this game system is for gamers who enjoy role-playing or combat simulation. If you really want a realistic simulation, most of the time would be spent travelling between star systems. The strategic mode robs players of information they would otherwise have in a 'Highly Real' Game System. BRIDGE CREW has been written to be fun as a game and does not have its roots in any Reality, especially the actual laws of physics. Copyright Mithril Software Page 46 How Sensors Work There are six types of sensors in the game. The FIP universe uses 5 of these, as EM, SE, WS, PS,and SR. The sixth is left unused for creative GMing by those GMs who have the Scenario Designers Kit. The shareware release ships do not use all 5 sensor types and sensors have different characteristics. Each starship has a basic reflective strength in each of the 6 types. To this is added a random factor (based on the reality that radar signatures on consecutive passes are rarely exactly the same due to atmospheric conditions and the way in which the aircraft is facing). This base reflective strength is shown by the "REPORT CROSSSECTION" report. Each starship sensor has a basic sensitivity in one specific type and a speed range which applies to the speed of objects it can detect. If the object's reflective strength plus the random factor is greater than the sensitivity of the sensor and the object is traveling within the sensor's speed range, then it will be visible to that sensor. Cloaking devices reduce the base reflective strength of one specific type while the device is turned on. (The only cloaking technologies I can actually think of were the de-gaussing coils on allied transports during World War II, the function of which was to prevent the triggering of magnetic mines)). Chameleon/camouflage techniques are, in a way, cloaking devices. Stealth techniques reduce the base reflective strength of the starship all the times and cost no energy (this is similar to modern aircraft technology). Examples Say a starship has a base SE reflectivity of 60. The viewing starship has a SE sensor with a sensitivity of 30 Because reflectivity is greater than sensitivity the ship will always be visible; this is because the maximum random addition is 20 and (60+20) is greater than 30. Say a starship has a base SE reflectivity of 10. The viewing starship has a SE sensor with a sensitivity of 40 Because reflectivity is less than sensetivity the ship will never be visible because the maximum random addition is 20, and (10+20) is less than 40 Say a starship has a base SE reflectivity of 15. The viewing starship has a SE sensor with a sensetivity of 30 Because reflectivity is within 20 less than sensitivity the ship, will sometimes be visible. This is because the maximum random Copyright Mithril Software Page 47 addition is 20 and (15+20) is greater than 30. However, the minimum addition is 1 and (15+1) is less than 30. This ship will tend to blink on and off - this is the type of situation used in the Rheman OWL class ship in the FIP universe. Footnotes GURPS, and Traveller are trademarks of Steve Jackson Games Incorporated. and Game Designers' Workshop. There are probably other trademarks owned by other companies in this document their presence is not infringe their owners rights in any way. Copyright Mithril Software Pty Ltd 1993,1994,1995 All rights reserved Copyright Mithril Software Page 48 CONTENTS Acknowledgements..........................................1 Introduction..............................................1 SOFTWARE INSTALLATION.....................................2 Setting up the software (Bcrewset.bat)....................2 Hardware Details (using COM1 and COM2)..................4 How Bridge crew handles multi port cards..................6 Getting Started...........................................8 Notes about How the Game Plays............................9 Game Mastering............................................12 Characters' Tour of Duty:.................................13 Running Campaigns.........................................14 Customising Your Universe.................................15 Role-play systems.........................................19 Player Commands...........................................20 The ORDER command.......................................22 GM Commands...............................................25 Captaincy styles and tactics..............................43 Hints and Tips............................................45 Limits of the Game........................................46 How Sensors Work..........................................47 Examples................................................47 Footnotes...............................................48